The modern communications era has brought about a tremendous expansion of wireline and wireless networks. Computer networks, television networks, and telephony networks are experiencing an unprecedented technological expansion, fueled by consumer demand. Wireless and mobile networking technologies have addressed related consumer demands, while providing more flexibility and immediacy of information transfer.
Current and future networking technologies continue to facilitate ease of information transfer and convenience to users by expanding the capabilities of mobile electronic devices. One area in which there is a demand to increase ease of information transfer relates to the sharing of information between multiple devices and potentially between multiple users. In this regard, given the ability for modern electronic devices to create and modify content, and also to distribute or share content, it is not uncommon for users of such devices to become prolific users and producers of media content such as for example photos, music, videos, etc. Networks and services have been developed to enable users to move created content to various points within the networks.
To complement mechanisms for distribution and sharing of personal content, mechanisms have also been developed to provide for distribution of content in various formats as well as facilitating conversion of content in one format to another format. For instance, the Digital Living Network Alliance (DLNA) is an industry collaboration forum that prepares guidelines used by producers of electronic devices to allow the electronic devices to share content with each other across a network such as for example a home network. DLNA guidelines rely on the Universal Plug and Play (UPnP) architecture, which defines basic functionality for digital media server devices and renderer devices, and discovery mechanisms for discovering the devices and their content on a home network. DLNA guidelines improve interoperability by defining some mandatory media formats that both servers and renderers are required to support, and they also define a number of optional media formats and related identifiers, so that it is possible to discover content that is stored on a server device in an optional media format that will play on a particular renderer device that supports the optional media format.
The DLNA Content Protection Subcommittee (CPS) is currently preparing Digital Rights Management (DRM) Interoperability Guidelines that are aimed at providing similar interoperability for DRM protected content, enabling a user to convert content that is in a particular DRM format to a different DRM format.
In this regard, two possible solutions have been identified for converting content from one DRM format to another DRM format. First, the content may either be converted from a first DRM format (also referred to herein as format A) into a second DRM format (also referred to herein as format B) by transcoding (also referred to as transcrypting) the content. In this regard, a device may decrypt the first DRM format and re-encrypt the content into the second DRM format. Second, the content may be acquired from a service that contains the content in multiple DRM formats (e.g., A, B, and C), and the service may provide the content in the desired DRM format (e.g., format B) to a device that requests or desires the content in that format, provided that the conditions set by a rights owner is met. For instance, if a user of a device is currently using content in a given DRM format (e.g. DRM format A) but desires the content in a different DRM format (e.g., DRM format B), the user may utilize a device to request the content in the desired format from a network entity of a service. An example of such a service is a Coral Ecosystem service, which uses interoperability solutions associated with different DRM formats that are provided by the Coral Consortium. This mechanism of obtaining content in a desired DRM format from a network entity of a service is referred to herein as reacquisition of the content or reacquiring the content.
Current approaches for reacquiring the content in a desired DRM format relates to instances in which content is downloaded from a network device of the Coral Ecosystem and provided to a device (also referred to herein as target device) that desires the content.
In a download scenario, a target device that desires the content in a DRM format, such as for example DRM format B, may request it from a source server and if the source server does not have the content in the desired DRM format, the source server may request the content in the desired DRM format from the Coral Ecosystem. The request will typically include a token that indicates that the target device has rights to use the content in another DRM format such as for example DRM format A and may indicate that the target device is capable of supporting DRM format B. The source server or the Coral Ecosystem may then check whether the rights to the content in the DRM format B can be granted to the target device, based at least in part on the data associated with the token and the source server or the Coral Ecosystem may deliver the content to the target device in DRM format B.
It should be pointed out that currently there are no suitable solutions for allowing a source device to upload content that the source device is capable of supporting in a DRM format to another electronic device, such as for example a target device. This is because there is currently no suitable mechanism available for the source device to determine the DRM formats that are supported by electronic rendering devices, in its network, that may play or render the content. It is worth noting that in accordance with the original DLNA/UPnP architecture, the rendering device that the user intends to use to render the content may be a different device than the target device to which the content is uploaded. If the DRM format capabilities of the electronic device that the user intends to use to play or render the content are not known to the source device, the source device may reacquire the content from a service such as for example the Coral Ecosystem service in a DRM format that the electronic rendering device is incapable of supporting. In this regard, the electronic rendering device would be unable to play or render the content once the content is uploaded to the target device since the electronic rendering device may not support the DRM format of the content.
For instance, consider an example in which a user of a server desires to upload content that it is capable of supporting to another electronic device in its network (e.g., home network) so that this electronic device may render or play the content. The server in this example may be capable of supporting desired content in DRM format A but may not have a locally stored copy of the content in DRM formats B and C. In this regard, the server may communicate with a target device and determine that the target device is capable of supporting the content in DRM formats B and C. Since the server only has the content locally stored in DRM format A the server may decide to request the content in DRM format B from a service such as the Coral Ecosystem service. The request will typically include a token that is used to prove that the server has possession of the content in DRM format A and that the target device may support content in DRM format B.
In this regard, the Coral Ecosystem may provide the content to the target device in DRM format B. In response, the target device may attempt to stream the content in DRM format B to an electronic device in its network with the intent that the electronic device will play the content. However, the electronic device may only be capable of supporting DRM format C and in this regard the electronic device will typically not be able to play the content. As such, current approaches for a source device to upload content to a target device so that another electronic device may render or play the content may result in problems associated with the electronic device being unable to use the content as well as drawbacks associated with disappointment and frustration for the user of the server, in this example. This is because the user of the server may have to utilize some other mechanism to provide the content to the electronic device in a DRM format that the electronic device is capable of supporting.
Using another approach to provide the electronic device with the content in an appropriate format may be a cumbersome and time consuming task since the user of the server may have to remove the content from the server, and save the content to another device that is capable of transcoding the content into a DRM format that is supported by the electronic device. The user may then need to attempt to upload (or stream) the content to the electronic device again, which may also frustrate the user due to the time involved to perform this task.
It should be pointed out that one approach to overcoming the drawbacks of the current approaches for a source device to upload content to a target device in a format supported by another electronic device that is intended to play the content is to ask the user which DRM formats that the electronic device utilizes. However, this approach requires user interaction and oftentimes the user does not know what DRM formats an electronic device on the network is capable of supporting. As such, this approach may still result in the electronic device being unable to play or render the content in an appropriate DRM format.
In view of the drawbacks described above, it may be desirable to provide an improved mechanism for uploading protected content to one or more electronic server devices in a DRM format that the electronic rendering devices are configured to support so that the intended electronic rendering devices may use or render the content.